1. Field of the Invention
This invention relates to data communications and data delivery over communication media between a host computer and a device, such as in host computer-based data acquisition systems.
2. Description of the Related Art
In many applications it is necessary or desirable for a host computer system to communicate data with an external device. Various transmission media and protocols exist for enabling communication between a host computer system and an external device. Examples of these types of external transmission media include IEEE 1394, the Universal-Serial Bus (USB), and other serial or parallel buses which enable packet-based communication. Also, a generic method to communicate data across multiple operating systems is desirable.
Typically, the host computer system includes communication logic for interfacing with the external communication line. For example, in a computer system which includes IEEE 1394 communication capabilities, the computer system includes an IEEE 1394 interface for communication through the IEEE 1394 bus. The computer system also typically includes various layers of driver software which allow an application to interface with and use the IEEE 1394 bus for communicating with the external device. One problem that often arises with host computer driver software which is used to interface to an external communication medium is that the host software requires numerous context switches between user mode and kernel mode. As is well known in the art, a user mode/kernel mode transition requires a context switch by the CPU. This generally requires a large amount of CPU resources or cycles to make the context switch each time a user mode/kernel mode transition occurs. Therefore, it would be desirable to provide a host computer driver software implementation which is operable to communicate with an external communication medium that minimizes user mode/kernel mode transitions.
Host computer software which interfaces to an external communication medium may also sustain passive/dispatch level transitions. Dispatch level is the highest level of software interrupt, just below hardware interrupts in priority. Passive/dispatch level transitions typically occur when a process running at dispatch level must wait for a response or for a resource to become available. Explicit ‘waits’ may not be performed at dispatch level, but must instead be performed at a passive level. For example, an interrupt routine handling non-page-locked memory must be executed at passive level because memory paging requires waiting. Similarly, synchronous communication (I/O) between a host computer and a 1394 device must be performed at passive level because the host computer must wait for responses from the 1394 device. Thus, a process running at dispatch level must transition to passive level to execute a task which entails an explicit wait. Also, many kernel functions are only meant to run at passive level. Therefore, between successive reads or writes, it is typically the case that a passive level routine requests a read/write operation. The Interrupt Service Routine (ISR) (running at dispatch) is dispatched upon completion of the transaction. The ISR copies data over, and signals to the passive level thread to continue with its next read/write. These transitions also result in a large amount of overhead on the host CPU. In particular, dispatch/passive transitions may degrade performance by several orders of magnitude due to passive level context switching in preemptive multi-tasking kernel systems, such as Microsoft Corporation's Windows NT 2000. Therefore, a system and method is also desired for reducing the number of passive/dispatch level transitions in the communication process.
A problem that frequently occurs in multi-threaded operating systems is that threads used for communicating with the external communication medium may be required to operate in a particular mode, such as user or kernel mode at passive or dispatch level. The operating system may allocate multiple threads in different time slots. Thus, threads used for managing the external communication medium may be interspersed with other threads that may be required to operate in a different mode, i.e., in a different user/kernel mode or at a different passive/dispatch level. This results in a large number of context switches by the CPU as the different threads are executed. Therefore, it would be desirable to provide a system which minimizes these types of context switches.
Another issue associated with host driver software related to external transmission media is the effort typically required to developed new drivers for particular buses and their related protocols. As is well known in the art, new driver software is generally written ‘from scratch’, because of the many dependencies of the software upon the operating system, the bus, and associated protocols. This approach requires significant resources in terms of both time and effort involved, and often impedes the rapid adoption and support of new transmission media and protocols. Therefore, an improved method and system for implementing driver software is desired.